Method for securing runtime execution flow

ABSTRACT

A runtime security system, including: a shared core configured to execute processes having varying levels of trustworthiness configured to receive security services requests; an execution monitor configured to monitor the execution of the shared core further comprising a timer, a policy table, and an execution monitor state machine; secure assets including cryptographic keys; and immutable security service functions configured to enable access to the secure assets in response to secure services requests; wherein the execution monitor is configured to: detect that the shared core has received a secure boot request; verify that the secure boot request is valid; allow the shared core to securely boot when the secure boot request valid.

TECHNICAL FIELD

Various exemplary embodiments disclosed herein relate generally to amethod for controlling and monitoring execution flow to assure securitysensitive functionality such that authenticate, attestation, and keymanagement are protected.

BACKGROUND

In prior systems, a reset secure boot provides the most assurance thatan “immutable”, fully deterministic instruction sequence will beexecuted as intended. This immutable process is the root-of-trust fromwhich the system securely establishes the runtime environment. Thus codeauthentication, integrity measurements, and high value crypto keyinstallation are performed at this “high assurance” time right afterreset. But this means the security state of the firmware, keys, etc.must be installed early and powered until the chip is powered off. Thiscan be costly in power consumption, especially in the case where higherperforming but power leaky cells are used for high throughputcryptographic accelerators.

SUMMARY

A brief summary of various exemplary embodiments is presented below.Some simplifications and omissions may be made in the following summary,which is intended to highlight and introduce some aspects of the variousexemplary embodiments, but not to limit the scope of the invention.Detailed descriptions of an exemplary embodiment adequate to allow thoseof ordinary skill in the art to make and use the inventive concepts willfollow in later sections.

Various embodiments relate to runtime security system, including: ashared core configured to execute processes having varying levels oftrustworthiness configured to receive security services requests; anexecution monitor configured to monitor the execution of the shared corefurther comprising a timer, a policy table, and an execution monitorstate machine; secure assets including cryptographic keys; and immutablesecurity service functions configured to enable access to the secureassets in response to secure services requests; wherein the executionmonitor is configured to: detect that the shared core has received asecure boot request; verify that the secure boot request is valid; allowthe shared core to securely boot when the secure boot request valid.

Various embodiments are described, wherein the execution monitor isfurther configured to set a timer related to an expected reaction timeof the shared core to the secure boot request.

Various embodiments are described, wherein the execution monitor isfurther configured to monitor an entry point of an instruction sequenceof the non-maskable secure boot request.

Various embodiments are described, wherein the execution monitor isfurther configured to: detect that the shared core has received anon-maskable secure services request; verify that an instruction relatedto the non-maskable secure services request is valid; and setting theprivilege level of the instruction based upon a policy evaluation usingthe policy table.

Various embodiments are described, wherein the execution monitor isfurther configured to revert the privilege level to a different trustlevel once the non-maskable secure services request has been completed.

Various embodiments are described, wherein the execution monitor isfurther configured to set a timer related to an expected reaction timeof the shared core to the non-maskable secure services request.

Various embodiments are described, wherein the shared core receivessecurity assets based upon the set privilege level.

Further various embodiments relate to a runtime security system,including: a shared core configured to execute processes having varyinglevels of trustworthiness configured to receive security servicesrequests; an execution monitor configured to monitor the execution ofthe shared core further comprising a timer, a policy table, and anexecution monitor state machine; secure assets including cryptographickeys; and immutable security service functions configured to enableaccess to the secure assets in response to secure services requests;wherein the execution monitor is configured to: detect that the sharedcore has received a non-maskable secure services request; verify that aninstruction related to the non-maskable secure services request isvalid; and setting the privilege level of the instruction based upon apolicy evaluation using the policy table.

Further various embodiments relate to a method of monitoring a sharedcore configured to perform functions having varying levels oftrustworthiness by an execution monitor, wherein the execution monitorincludes a timer, a policy table, and an execution monitor statemachine, including: receiving a secure boot request by a shared core;detecting, by the execution monitor, that the shared core has received asecure boot request; and verifying that the secure boot request isvalid; allowing the shared core to securely boot when the secure bootrequest valid.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand various exemplary embodiments, referenceis made to the accompanying drawings, wherein:

FIG. 1 illustrates an embodiment of a secure runtime system;

FIG. 2 illustrates the state transition diagram for the executionmonitor state machine;

FIG. 3 illustrates the interaction between the execution monitor statemachine and a policy table;

FIGS. 4A, 4B, and 4C illustrate logic used for policy checking by theexecution monitor; and

FIG. 5 illustrates the control of bus transaction privileges foraccessing the security assets.

To facilitate understanding, identical reference numerals have been usedto designate elements having substantially the same or similar structureand/or substantially the same or similar function.

DETAILED DESCRIPTION

The description and drawings illustrate the principles of the invention.It will thus be appreciated that those skilled in the art will be ableto devise various arrangements that, although not explicitly describedor shown herein, embody the principles of the invention and are includedwithin its scope. Furthermore, all examples recited herein areprincipally intended expressly to be for pedagogical purposes to aid thereader in understanding the principles of the invention and the conceptscontributed by the inventor(s) to furthering the art, and are to beconstrued as being without limitation to such specifically recitedexamples and conditions. Additionally, the term, “or,” as used herein,refers to a non-exclusive or (i.e., and/or), unless otherwise indicated(e.g., “or else” or “or in the alternative”). Also, the variousembodiments described herein are not necessarily mutually exclusive, assome embodiments can be combined with one or more other embodiments toform new embodiments.

Increasingly with internet of things (IoT) applications, security checksare needed “on demand” e.g., to have a device assuredly attest to theintegrity of itself when the request is from a remote network managementserver.

In heterogeneous multi-core chips, many of the cores may be runningsomewhat unsecure software but connect to external entities that need toassuredly authenticate the device. Fault injection attacks are on therise as products are now available to make it easy for fine-grainedcontrol of such attacks. Without monitoring, an instruction sequence may“skip” a critical security step, undetected.

As a result there is a need for a practical method for a secure run timeexecution flow stemming from a root-of-trust with monitoring that meetsor exceeds the same assurances as the boot time flow to perform codeauthentication, code measurement (attestation), signatures, and cryptokey installation.

The techniques and embodiments described herein demonstrate how a rootof trust is used to initiate security functions in the runtime whenneeded to save power and lessen risk of exposure or modification ofsensitive information and controls. These embodiments allow for sharingof an off-the-shelf microcontroller core with non-secure software forlow cost, resource-constrained devices.

FIG. 1 illustrates an embodiment of a secure runtime system. The secureruntime system 100 may include a shared core microcontroller 105, anexecution monitor 110, resident software 115, immutable security servicefunctions 120, security assets 125, a handshaking queue 130, privilegeassignment function 135, a queue with/ID 155, read only memory (ROM)170, general purpose input/output (GPIO) 175, private data bus 190, andfirewalls 140, 145, 150, 180, 185, 186, 187, and 188. The secure runtimesystem 100 may communicate with a system 165 that sends security servicerequests to the secure runtime system 125. The system 165 may beinternal or external to a system on chip (SoC) that includes the secureruntime system 100. A system security monitor 160 may also receiveindications of tampering or integrity issues and provide an integritymonitor signal to the execution monitor 110. The secure runtime systemmay also be called a runtime root of trust system.

The execution monitor 110 may include reference information 111, anexecution monitor state machine 112, a timer 113, and a policy table114. The execution monitor 110 monitors critical signals and setsspecific access privilege to security assets. The execution monitor 110will be described in more detail below. The execution monitor 110 may beimplemented in hardware. Such hardware implementation may includeconfigurable hardware and may include memory and a controller.

The shared core 105 may be a microcontroller that allows bothapplication code with varying levels of trustworthiness and trustedsecurity services. The shared core 105 may be any type of processorincluding a microprocessor. The shared core 105 may be low cost devicethat is used in cost sensitive application where security is still animportant requirement. The shared core 105 also may be an unsecuredprocessor. Associated with the shared core 105 is ROM 170. The ROM 170stores code that are immutable instructions. The resident software 115may fetch instructions from the ROM 170.

The immutable security service functionally 120 includes functions thatenable access to security assets 125 when entered properly. Theimmutable security service functionality 120 will typically beimplemented using secure hardware. The security assets 125 are aprotected area with confidentiality and integrity critical parameters,e.g., cryptographic keys, with access controls aligned to the executionmonitor privilege enumeration. The security assets 125 provide thesecure information in response to requests for a specific securityasset. The immutable security service functionality 120 and the securityassets 125 may be behind firewalls 140 and 145. The firewalls 140 and145 allow for only authorized access via security service requests toeither the immutable security service functionality 120 or the securityassets 125.

The queue w/ID 155 receives security service requests and then providesauthorized security service requests to the shared core 105. Securityservice requests provide non-maskable requests to the shared core 105.This access is protected and the identity of what made the request iscaptured on the bus. This identity is not set by the requesting softwarebut from the underlying source channel input (e.g., core, I/O, privilegemode).

The privilege assignment function 135 assigns the privileges associatedto requests from the shared core 105 to access the immutable securityservice functions 120, security assets 125, resident software 115, andthe private bus 190. The privilege assignment function 135 is controlledby the execution monitor 110.

The private bus 190 provides for external access to the secretinformation. This bus is protected by a firewall 185 that screens theincoming requests. Further, a firewall 186 controls the access to theresident software 115 by the private bus 190. A firewall 188 controlsthe access to the execution monitor 110 by the private bus 190.

The GPIO provides the ability to have a general input/output access tothe secure runtime system 100. It allows for communication with othersystems that are off core and off chip. A firewall 187 controls theaccess to the private bus 190 by the GPIO 175.

The operation of the secure runtime system 100 will now be described.

The system 165 indicates to a resident process (not security service)running on the shared core 105 via handshaking queue 130 that a securityservice request will be sent shortly to the shared core 105.Alternatively, a resident process running on the shared core 105 maymake a security service request.

The resident process executing on the shared core then saves its stateand sends back to the system 165 via the handshaking queue 155 anacknowledgement that shared core is ready to receive the securityservice request. If the resident process does not behave properly inresponse to the handshake protocol, then the system 165 may directlyinterrupt the misbehaving resident process, and then the residentprocess may be re-authenticated and run via security service call,re-booted in the runtime without a reset.

The system 165 then sends the security service request to the queue w/ID155. A source identity (ID) is transferred along with the requestmessage and captured in the queue w/ID 155. The queue w/ID 155 alsoincludes a firewall that rejects requests from unauthorized sources. Foran authorized requesting source, the identity is used to apply accessand services policies in the service monitor 110.

The queue w/ID 155 sends a non-maskable request to the shared core 105.The non-maskable request triggers/forces execution of the shared core105 to an immutable command handler, e.g., non-maskable interrupt (NMI)handler in ROM.

The execution monitor detects the trigger, changes the state of the EMstate machine 112 to a first state, captures the requestor's ID, andsets the timer to a time related to an expected reaction time of theshared core 105 to non-maskable request.

The shared core 105 fetches an immutable instruction from the requesthandler e.g., from ROM. In the request handler is an instruction to sendan acknowledgement of the request to the execution monitor 110.

The execution monitor 110 detects the instruction fetch to the exactlocation of the command handler address. This causes the EM statemachine 112 to advance to the second state, and the execution monitor110 resets the timer 113 that was awaiting the acknowledgement.

The request handler process sends the expected acknowledgement whichcauses the EM state machine 112 to advance to a third state, and theexecution monitor 110 restarts the timer.

At this point the checks have occurred as expected and a single securityservice invocation will be given privilege by the execution monitor 110based on the ID and a policy evaluation by the execution monitor 110 toallow the shared core 105 to access specific security assets (e.g.,keys, measurements, functions). The privilege is granted by setting theshared core privilege assignment value. The immutable security servicefunction executes on the shared core 105, and other requests or signalscannot alter the execution flow of the shared core 105 or instructionpointer. Privileges are set so that instructions cannot be fetched fromfunctions with various levels of trustworthiness.

If there are multiple security services with corresponding privileges(not necessarily hierarchical) the execution monitor 110 detects theinstruction to the specific command address and awaits acknowledgementas each command has its own acknowledgment. The shared core 105 awaitsreceiving the status.

The execution monitor 110 verifies the command according to policy andrequestor ID. Policy permitting, the execution monitor 110 adjusts theprivilege assignment and sets the status.

The shared core 105 receives status and accesses security assets 125.

Once the shared core immutable process is complete, the shared core 105sends a final acknowledgement to the execution monitor 110. Theexecution monitor 110 then reverts the privilege assignment 135 to theprevious trust level and resets the execution monitor state machine 112.

The operation of the execution monitor state machine 112 will now bedescribed. FIG. 2 illustrates the state transition diagram for theexecution monitor state machine 112. The execution monitor state machine112 includes the following states: RESET 205; REQ 210; START 215; EXEC220; and KFYS 225.

At the RESET state 205, a non maskable interrupt is issued to the securecore 105. This causes the secured core 105 to jump execution to the ROMaddress space. This address is a hardcoded value and cannot be changed.

When a system non-masked interrupt (NMI) occurs, the execution monitorstate machine 112 transitions 230 to the REQ state. Also, the timer 113is started by the execution monitor 110. Once this NMI is received, theexecution monitor 110 snoops the address lines of the ROM and looks foran address match on the handler address being executed. In the REQ state210, if there is a handler exit, a timer timeout, or the shared coreenters a non-secure state, then the execution monitor state machine 112transitions 235 back to the RESET state 205. Otherwise, the executionmonitor state machine 112 awaits an NMI entrance 240. Once there is anNMI entry 245 due to an instruction fetch at a specific address (i.e.,an address match), the execution monitor state machine 112 transitions245 to the START state 215.

In the START state 215, once the handler execution starts, the handleracknowledges that it seeks access to the security assets 125. In theSTART state 215, if there is a handler exit, a timer timeout, or theshared core enters a non-secure state, then the execution monitor statemachine 112 transitions 255 back to the RESET state 205. Otherwise, theexecution monitor state machine 112 awaits a handler acknowledgement250. The execution monitor 110 will not receive inputs through this portuntil the first states have successfully completed. Once the handleracknowledges the NMI, the execution monitor state machine 112transitions 260 to the EXEC state 220.

In the EXEC state 220, a specific service such as key reads is requestedby an immutable execution command. In the EXEC state 220, if there is ahandler exit or the shared core enters a non-secure state, then theexecution monitor state machine 112 transitions 270 back to the RESETstate 205. Otherwise, the execution monitor state machine 112 waits forkey reads to be enabled 265. Once the key read is enabled, the executionmonitor state machine 112 transitions 275 to the KEYS state 225.

In the KEYS state 220, once the core is done reading the keys, it exitsthis NMI process. In the KEYS state 225, if there is a handler exit orthe shared core enters a non-secure state, then the execution monitorstate machine 112 transitions 280 back to the RESET state 205.

If at any time during the operation of the execution monitor statemachine 112, the timer times out, a security breach, or policy failureoccurs, the executions monitor state machine 112 resets, and a newrequest is needed to restart the process

FIG. 3 illustrates the interaction between the execution monitor statemachine 112 and a policy table. The execution monitor state machine 112interacts with the shared core 105, policy table 114, and the timer 113.Only after a prescribed sequence of execution events and conditions canaccess be granted. The execution monitor state machine 112 isautomatically initiated upon an allowed request event.

The policy table 112 provides privilege control 365 based on the state360 of the execution monitor state machine 112, request ID 310,monitored address 370, monitored mode 375, and command 305. While thestate 360 determines if access may be allowed (i.e., because theexecution flow is verified), the privilege control 365 provides finergrain and separation in a multi-requestor system. Policy table 114 canprogress 355 or reset 350 the execution monitor state machine 112,depending on policies defined in the policy table 114 based upon thevarious inputs.

A command is provided from the shared core 105 after a non-maskablerequest 330 is received and execution has begun, when the address hasbeen checked. Therefore command 305 and request ID 310 are trustedvalues.

The shared core 105 may also send a reset 315 and ACK 320 to theexecution monitor state matching 112. The execution monitor statemachine 112 may also receive an integrity indicator 335, chip lifecyclevalue 340, and a time out indicator 345.

FIGS. 4A, 4B, and 4C illustrate logic used for policy checking by theexecution monitor 110. As shown in FIG. 4A, the execution monitor 112checks the instruction address (monitored address) against an expectedaddress, which may change depending on the state of the executionmonitor state machine 112. Further, the state may be in part dependentupon the command. More specifically, a selector 400 may receive areference address 1 404, a reference address 2 406, up to a referenceaddress N 408, and the state of the execution monitor state machine 112.One of the reference addresses (404, 406, and 408) is selected basedupon the state to produce an expected address 402. Next, a comparator412 received the expected address 402 and a monitored address 414 anddetermines if they match. If they do match, then the state of theexecution monitor state machine 112 is progressed 416. If they do notmatch, then the execution state machine 112 is reset 418.

As shown in FIG. 4B the requestor is checked. The shared core 105provides the requestor's ID 422 and the received command 424 and it isdetermined if the received command 424 is allowed for the requestor 420.If the requestor is allowed to request the specified command, then thestate of the execution monitor state machine 112 is progressed 426. Ifthe command is not allowed, then the execution state machine 112 isreset 420. The requestor's ID 422 and the received command 424 aretrusted at this check.

FIG. 4C illustrated how the privilege control may be determined. Theprivilege control 440 depends on the execution monitor state, thecommand, and the requester's ID. For example, if the state 410 andcommand 424 are the same, different requester's ID 422 might result indifferent access permissions or locations. Privilege control 440 is atemporary window of access until the shared core 105 exits the immutablesequence and resets the state. A selector 430 may receive privilegevalues 1-N 434, 436, 438. The selector 440 also received the requestorID 422, command 424, and state 410, and the selector 440 uses theseinputs to select one of the privilege values 434, 436,438 as theprivilege control 440.

FIG. 5 illustrates the control of bus transaction privileges foraccessing the security assets. The privilege assignment 135 receivesrequests from the shared core 105 and also a privilege control 440 fromthe execution monitor 112. Based upon this information, the privilegeassignment 135 determines the bus privilege 410 for the requests fromthe shared core 105. The privilege assignment 15 send the request 405and bus privilege 410 to the firewalls 140, 145. The firewall thenenables access to the various elements of the security assets 125. Thesecurity assets may include RAM 415, security fuses 420, resident codeauthenticated 425, and content protection module 450. To access thecontent protection module 430, the firewalls 140, 145 may send a systemenable 435, an authentication 440, and content keys 445. The contentprotection mode then grants system access 450 based upon these inputs.

The following table provides examples of how bus transaction privilegesmay be implemented. In this example there are six regions. For each ofthe regions specific privileged IDs are permitted as shown, and then thefirewalled data to be accessed is defined.

Firewall Region Privileged IDs Permitted Firewalled Data Region Internalnetwork subsystem Intranet authentication credentials. 1 RegionExecution monitor code Execution monitor authentication 2 credentials(e.g., manufacturing protections) Region Authenticated reside Securityfuses, monotonic counter, 3, 4 code (verified as part resident secretsof request command) Region Connectivity subsystem Attestation functionand registers 5 (signed by execution monitor and ca include requestorID) Region Application subsystem has Content protection module 6privilege to use but does (controls, firmware authentication, not havevisibility or and keys) direct control

The embodiments described herein provide a variety of benefits asfollows. The embodiments described provide on-demand (i.e., as needed)security functions and cryptographic key access for low power. Thesefunctions are only provided power when needed. The embodiments alsoprovide active monitoring for proper security function entry point. Theembodiments provide separation of privilege between ROM, software coderunning on the same core, and the system. Further, cryptographic keysare only available during a narrow window of time, when needed, tolessen risk of exposure. Further, the embodiments use an off-the-shelfcore, thus there is no need for special microcontroller.

The embodiments provide that the timing for flow from interrupt signalto execution of first code of the key management handler isdeterministic. The embodiments described also provide robustness againstfault injection attacks. These embodiments also allow for sharing of asmall core for both security services and less trusted software forresource constrained devices, thus leading to a lower cost system.

Any combination of specific software running on a processor to implementthe embodiments of the invention, constitute a specific dedicatedmachine.

As used herein, the term “non-transitory machine-readable storagemedium” will be understood to exclude a transitory propagation signalbut to include all forms of volatile and non-volatile memory. Further,as used herein, the term “processor” will be understood to encompass avariety of devices such as microprocessors, field-programmable gatearrays (FPGAs), application-specific integrated circuits (ASICs), andother similar processing devices. When software is implemented on theprocessor, the combination becomes a single specific machine.

It should be appreciated by those skilled in the art that any blockdiagrams herein represent conceptual views of illustrative circuitryembodying the principles of the invention.

Although the various exemplary embodiments have been described in detailwith particular reference to certain exemplary aspects thereof, itshould be understood that the invention is capable of other embodimentsand its details are capable of modifications in various obviousrespects. As is readily apparent to those skilled in the art, variationsand modifications can be effected while remaining within the spirit andscope of the invention. Accordingly, the foregoing disclosure,description, and figures are for illustrative purposes only and do notin any way limit the invention, which is defined only by the claims.

What is claimed is:
 1. A runtime security system, comprising: a sharedcore configured to execute processes having varying levels oftrustworthiness configured to receive security services requests; anexecution monitor configured to monitor the execution of the shared corefurther comprising a timer, a policy table, and an execution monitorstate machine; secure assets including cryptographic keys; and immutablesecurity service functions configured to enable access to the secureassets in response to secure services requests, wherein the executionmonitor is configured to: detect that the shared core has received asecure boot request; verify that the secure boot request is valid duringa temporary window of access based upon a state of the executionmonitor, a received command, and a requestor ID: and allow the sharedcore to securely boot when the secure boot request is valid; wherein theexecution monitor is further configured to set the timer related to anexpected reaction time of the shared core to the secure boot request. 2.The runtime security system of claim 1, wherein the execution monitor isfurther configured to monitor an entry point of an instruction sequenceof the secure boot request.
 3. The runtime security system of claim 1,wherein the execution monitor is further configured to: detect that theshared core has received a non-maskable secure services request; verifythat an instruction related to the non-maskable secure services requestis valid; and set a privilege level of the instruction based upon apolicy evaluation using the policy table.
 4. The runtime security systemof claim 3, wherein the execution monitor is further configured torevert the privilege level to a different trust level once thenon-maskable secure services request has been completed.
 5. The runtimesecurity system of claim 3, wherein the execution monitor is furtherconfigured to set the timer related to an expected reaction time of theshared core to the non-maskable secure services request.
 6. The runtimesecurity system of claim 3, wherein the shared core receives securityassets based upon the set privilege level.
 7. A runtime security system,comprising: a shared core configured to execute processes having varyinglevels of trustworthiness configured to receive non-maskable securityservices requests; an execution monitor configured to monitor theexecution of the shared core further comprising a timer, a policy table,and an execution monitor state machine; secure assets includingcryptographic keys; and immutable security service functions configuredto enable access to the secure assets in response to non-maskable secureservices requests, wherein the execution monitor is configured to:detect that the shared core has received a non-maskable secure servicesrequest; verify that an instruction related to the non-maskable secureservices request is valid during a temporary window of access based upona state of the execution monitor, a received command, and a requestorID: and set a privilege level of the instruction based upon a policyevaluation using the policy table; wherein the execution monitor isfurther configured to set the timer related to an expected reaction timeof the shared core to the non-maskable secure services request.
 8. Theruntime security system of claim 7, wherein the execution monitor isfurther configured to monitor an entry point of an instruction sequenceof the non-maskable secure services request.
 9. The runtime securitysystem of claim 7, wherein the execution monitor is further configuredto revert the privilege level to a different trust level once thenon-maskable secure services request has been completed.
 10. The runtimesecurity system of claim 7, further comprising: a handshake queueconfigured to perform a handshake protocol with a system sending secureservices requests to the shared core.
 11. The runtime security system ofclaim 7, further comprising: a queue with ID configured to receivesecurity services requests and the requestor ID from a system andprovide the security services requests to the shared core based upon therequestor ID.
 12. The runtime security system of claim 7, furthercomprising: a system security monitor configured to provide an integrityindicator to the execution monitor based upon a tamper or integrityissued indication.
 13. A method of monitoring a shared core configuredto perform functions having varying levels of trustworthiness by anexecution monitor, wherein the execution monitor includes a timer, apolicy table, and an execution monitor state machine, the methodcomprising: receiving a secure boot request by a shared core; detecting,by the execution monitor, that the shared core has received the secureboot request; verifying that the secure boot request is valid during atemporary window of access based upon a state of the execution monitor,a received command, and a requestor ID: and allowing the shared core tosecurely boot when the secure boot request is valid; setting, by theexecution monitor, the timer related to an expected reaction time of theshared core to the non-maskable secure services request.
 14. The methodof claim 13, further comprising: receiving a non-maskable secureservices request by the shared core; detecting, by the executionmonitor, that the shared core has received a non-maskable secureservices request; verifying, by the execution monitor, that aninstruction related to the non-maskable secure services request isvalid; and setting, by the execution monitor, a privilege level of theinstruction based upon a policy evaluation using the policy table. 15.The method of claim 14, wherein the shared core receives security assetsbased upon the set privilege level.
 16. The method of claim 14, furthercomprising; reverting, by the execution monitor, the privilege level toan un-trusted level once the non-maskable secure services request hasbeen completed.